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Abstract — Tor, the most popular deployed distributed onion 
routing network, suffers from performance and scalability prob- 
lems stemming from a lack of incentives for volunteers to 
contribute. Insufficient capacity limits scalability and harms the 
anonymity of its users. We introduce LIRA, a lightweight scheme 
that creates performance incentives for users to contribute band- 
width resources to the Tor network. LIRA uses a novel crypto- 
graphic lottery: winners may be guessed with tunable probability 
by any user or bought in exchange for resource contributions. 
The traffic of those winning the lottery is prioritized through 
Tor. The uncertainty of whether a buyer or a guesser is getting 
priority improves the anonymity of those purchasing winners, 
while the performance Incentives encourage contribution. LIRA 
is more lightweight than prior reward schemes that pay for 
service and provides better anonymity than schemes that simply 
give priority to traffic originating from fast relays. We analyze 
lira’s efficiency, anonymity, and incentives, present a prototype 
implementation, and describe experiments that show it indeed 
improves performance for those servicing the network. 

I. Introduction 

Onion routing [1], particularly as deployed in Tor [2], [3] 
is the most widely used and extensively studied approach to 
anonymous communication. By protecting who is talking to 
whom and who is accessing which networks, Tor is a desirable 
tool for a variety of users. Its users include, but are not 
limited to: web users concerned about privacy; journalists, 
intelligence agents, and law enforcement agents concerned 
about hiding their operations; political activists concerned 
about surveillance from their government or from political op- 
ponents; and businesses concerned about industrial espionage 
or competitive intelligence. 

Predominantly designed to provide anonymity for its users. 
Tor works by sending client traffic through multiple relays 
after encrypting it once for each relay in the circuit. Each relay 
decrypts and forwards traffic through the circuit as specified 
by the client. This traffic encryption and decryption process 
prevents a single member of the circuit from linking the user 
to its intended Internet destination. As it is paramount to Tor’s 
design, anonymity has been improved by other design aspects: 
frequently rotating circuits and selecting the first relay from 
a small set of guards helps defend against passive logging 
attacks [4], [5] and further strengthens users’ privacy. 
Limited Capacity and Scalability. Tor relays are run by 
volunteers who altruistically contribute bandwidth and com- 
putational resources to the network. As a result. Tor is usable 


even by those unable or unwilling to contribute because they, 
e.g., have slow connections or are behind restrictive firewalls. 
Unfortunately, network capacity is limited to these altruistic 
contributions and has increased sublinearly to Tor’s popularity. 
In Tor’s current resource model, its popularity harms its us- 
ability and performance, and may therefore have a significant 
negative impact on its users’ anonymity [6], [7]. The Tor 
Project [3] has enumerated many performance problems they 
have recognized and are actively pursuing designs that improve 
the network in this regard [8]. Recent work has focused 
on reducing the existing load on the network [9], [10] and 
optimizing utilization of the existing resources [1 1], [12], [13], 
but bolstering capacity while at the same time encouraging 
scalability remains a challenging open problem. 

Various responses to this capacity and scalability problem 
have been considered. Thus far Tor has relied on community 
support to provide much-needed boosts to its capacity. For 
example, Torservers.net [14] is a registered German non-profit 
organization that uses donations to purchase or rent high- 
bandwidth servers for the public Tor network. Similarly, the 
Electronic Frontier Foundation ran a “Tor Challenge” in which 
they encouraged people to set up relays and listed the names 
of those who chose to be acknowledged for doing so [15]. 
Unfortunately, the support is limited and inadequate for Tor 
to scale to millions of simultaneous users while remaining 
usable. Currently Tor is initiating direct funding of relays using 
government funding it receives for this purpose. As noted in 
the blogpost announcement, this raises numerous questions, 
such as the impact on diversity of the infrastructure [16]. 
Another unknown is the sustainability of any resulting capacity 
increase if this direct funding ceases. 

A more scalable way to increase capacity is to require all 
users to contribute in a peer-to-peer fashion. However, not 
only would it be difficult to force users to comply, this would 
also turn away some of those most in need of its protections 
due to an inability to contribute. Further, combined with a 
potential lack of user interest in operating and maintaining 
servers, this strategy may produce undesirable low bandwidth 
or unstable relays that increase network bottlenecks and may 
actually harm performance [17]. 

Numerous proposals to recruit new relays using incentives 
have appeared in the literature. Although the incentive ap- 
proach is promising, past designs have thus far been plagued 


with anonymity or efficiency problems. Both the “gold star” 
scheme [18] and Tortoise [9] have serious anonymity problems 
that allow relays’ traffic to be identified, while PAR [19], 
XPAY [20], and BRAIDS [21] do not not scale well due 
to inefficient protocols. Our goal in this work is to design 
and evaluate a system that combines strong anonymity with 
scalable efficiency. 

Lightweight Incentivized Routing for Anonymity. We 

present LIRA, a unique and scalable approach to creating 
incentives for users to contribute computational and bandwidth 
resources to Tor. Proportionally differentiated services [22] 
are the foundation for incentives: users who choose to run 
relays will be able to proportionally increase their performance 
relative to those not contributing. Further, relays may con- 
tribute more resources to increase the amount of their traffic 
that gets prioritized, leading to greater network capacity and 
performance improvements for everyone. At the same time, 
LIRA frustrates the adversary’s ability to utilize traffic priority 
as a distinguisher of client-initiated and relay-initiated circuits. 

LIRA produces incentives with a novel cryptographic lottery 
design together with a new circuit scheduling algorithm that 
prioritizes traffic from those winning the lottery. To play the 
relay lotteries, clients send a ticket to each relay in each circuit 
built in LIRA. Clients generate random number guesses to 
produce tickets locally, each of which will be a winner for 
a relay lottery with a tunable probability. Relays contributing 
resources may collect anonymous coins proportional to their 
contributions, and exchange the coins for guaranteed winners 
to relay lotteries of their choosing. Relays differentiate perfor- 
mance by prioritizing traffic for winning circuits. 

LIRA maintains anonymity. An adversary in LIRA is un- 
able to distinguish relays’ purchased winners from clients’ 
guessed winners, whereas an adversary in the “gold star” [18] 
and Tortoise [9] incentive designs can determine that traffic 
initiated from relays with absolute certainty. LIRA provides 
tunable anonymity: increasing the probability that a guessed 
ticket is a winner reduces the adversary’s certainty about the 
traffic source. 

LIRA is lightweight. Previous schemes either require that 
an online trusted third party participates in routing in order 
to prevent double spending, as in PAR [19] and XPAY [20], 
or that the third party distributes tickets to all relays and 
all clients, as in BRAIDS [21]. Neither of these approaches 
scales well to millions of simultaneous users. LIRA is scalable 
because purchased tickets are not managed for clients, but only 
for the orders of magnitude smaller set of relays, and there is 
no spending transaction when circuits are built. 
Contributions. This work’s major contributions may be sum- 
marized as follows: 

• A unique and novel cryptographic lottery approach to 
providing incentives to run Tor relays that combines 
strong anonymity with scalable efficiency 

• A new Tor circuit scheduler that produces performance 
incentives through proportional throughput differentiation 

• A detailed efficiency, anonymity, and incentive analysis 
and comparison to BRAIDS [21], the state-of-the-art Tor 


incentive design 

• A prototype implementation and experimental validation 
that LIRA provides incentives to contribute 
Outline. The rest of the paper is outlined as follows. Section II 
provides details about the network, our threat model, and our 
objectives. LIRA’S technical design is given in Section III, 
while Section IV analyzes LIRA’S efficiency, anonymity, and 
incentives. Our protoype and experimental evaluation are 
described in Section V, Section VI discusses related work, 
and Section VII concludes. 

II. Preliminaries 

We now discuss specific details about the deployed Tor 
network that LIRA’S design considers and describe the circuit 
building protocol to facilitate an understanding of how we 
will propose to modify it. We also introduce a bank as an 
additional service that will be utilized in LIRA’S design, 
specify our adversarial threat model, and clarify the objectives 
of our system. Though LIRA could be applied to various 
anonymous communication systems, our exposition will focus 
on the Tor [2] onion routing network. 

Onion-Routing Network. The most popular instantiation of 
onion routing [1], the Tor overlay network includes a directory 
service that publishes information about the available relays. 
Using the directory information, clients build three-hop cir- 
cuits that begin with one of a small set of entry guard relays 
and end with an exit relay willing to connect to the client’s 
desired Internet service. A circuit is built through a telescoping 
process: an encrypted tunnel is first created to an entry guard, 
after which the tunnel is extended one relay at a time until the 
circuit is completely established at the exit relay. During this 
building process, the client negotiates an ephemeral key with 
each relay in the circuit using a Diffie-Hellman key exchange 
protocol. Once established, client TCP streams that conform to 
the exit relay’s exit policy may be multiplexed over the circuit 
for ten minutes, after which the circuit will be marked as 
dirty and will not permit any new application connections. The 
circuit is destroyed once existing application connections are 
done using it. All data transferred over the circuit is packaged 
into uniform-sized cells and encrypted using the negotiated 
ephemeral keys. 

A relay may be servicing several circuits at any given 
time. Every circuit that results in data exchange between 
any pair of relays is multiplexed over a single TCP onion- 
routing connection between the pair. Cells read from this 
connection are processed and placed in a scheduling queue 
before being switched onto the corresponding outgoing onion- 
routing connection to the next-hop relay. 

Roughly 3000 geographically diverse Tor relays currently 
transfer a combined total of about 1700 MiB/s from an esti- 
mated 400,000 unique users per day [23]. We parameterize the 
onion-routing network size for design and analysis purposes 
as m onion routers and n unique users in a given time 
period. We also assume the existence of a new bank service 
B. The bank will assist both in establishing valid lotteries 
with the relays and in assessing and rewarding contributions 



Fig. 1; An overview of LIRA’S design, (a) Relays coordinate with the bank to learn which tickets will be winners for their lottery, 
(b) Relays accumulate anonymous coins by contributing bandwidth to Tor, and may exchange them for guaranteed winners 
to other relay lotteries, (c) Clients send either guaranteed winners or guesses through their circuits. Relays proportionally 
differentiate throughput by prioritizing circuits that submitted winners to every circuit position. 


(see Section III). We will assume that all entities can use 
the underlying communication network to send each other 
messages directly. 

Adversary. We will consider the actions of both a malicious 
network adversary and an honest-but-curious {i.e. passive) 
bank. We use the standard network adversary for onion rout- 
ing [24], which is local in that he can observe part of the 
network, is active in that he can perform computations, send 
messages, run onion routers, and act as a client. Although in 
this paper we model the bank as a single entity, we expect 
the ultimate implementation of the bank to be similar to that 
of the directory service in the current public Tor network; 
multiple entities run the service and form a consensus on the 
authoritative documents. Therefore, we assume that the bank 
faithfully executes the protocol and only makes observations 
that are part of that protocol. In particular, he does not act as 
an onion router or as a client, only observes messages that are 
sent to him, and does not collude with the network adversary. 
Objectives. Our goal is to provide incentive for anonymous- 
network users to run relays while preserving the desirable 
features of onion routing. Therefore, we will evaluate LIRA 
in terms of its functionality, its efficiency, the anonymity it 
provides, and the incentive it offers to run a relay. 

We require that our system provide the functionality pro- 
vided by onion routing. In particular, it should provide bidirec- 
tional, stream-oriented, low-latency communication between 
pairs of users. In addition, the responder of a stream should 
only need to run a standard transport protocol so users can 
communicate with destinations that aren’t aware of or designed 
for anonymous communication protocols. 

We also require that the efficiency of our system is com- 
parable to onion routing. The success of Tor over alternative 
anonymous-communication protocols can be attributed in large 
part to its relatively low computational and communication 
costs. In particular, our protocol should have costs for each 
user that are proportional to amount of his anonymized traffic 
and for relays as a group that are proportional to the total 
amount of anonymized traffic. Moreover, we want the resource 
requirements at the bank to be achievable under current Tor 


network conditions and to scale well with a growing network. 

Our evaluation will consider relationship anonymity [24] 
in our system, that is, the extent to which users can be 
linked to their communication partners. We will measure this 
using the probability that an adversary assigns to a user 
communicating with his actual destinations. We will also 
evaluate the incentives provided by LIRA. As it is designed 
to improve throughput and latency for users running relays, 
we will measure this performance difference while also con- 
sidering the extent to which a user can cheat and obtain these 
improvements without contributing. 

III. Design 

To achieve the objectives stated in Section II, LIRA em- 
ployes a cryptographic lottery and a relay circuit scheduler that 
prioritizes traffic for users who submit winning lottery tickets. 
A high level overview of LIRA’S design and the interactions 
between these mechanisms is given in Figure 1 . Through coor- 
dination with the bank, the relays receive information allowing 
them to recognize winning tickets to their own lottery (see Fig- 
ure la). Over time, relays accumulate anonymous electronic 
coins from the bank by providing service to the network. These 
coins may be exchanged for guaranteed winning ticket values 
for a variety of relay lotteries (see Figure lb). Clients without 
coins guess ticket values to produce them locally: their guesses 
will be winners with tunable probability. Tickets are passed 
to the relays through circuit control messages, and relays 
cannot distinguish a guessed winner from a guaranteed winner. 
Relays in every circuit position verify tickets and prioritize 
circuits of submitted winners by proportionally increasing their 
throughput (see Figure Ic). We now describe LIRA’S design 
in further detail. 

A. Setup 

The bank will use RSA blind signatures [25], which allow 
it to sign a message without being able to link the signature 
with an earlier signing request. Let M be the RSA modulus 
of the bank, e be the public encryption exponent, and d be 
the corresponding private decryption exponent. Each relay r 


will need a public random value Xr € associated with it. 
These values can be generated by the bank and distributed by 
the directory service. For each relay r, the bank computes its 
signature xf and sends it to r. Finally, the system will use a 
full-domain hash function H : {0, 1}* — > {0, where A 
denotes the security parameter for the system. We can use a 
cryptographic hash function such as SHA-1 for H. 

B. Coin Distribution 

LIRA rewards relays proportional to the amount of band- 
width they contribute. Since relays can not be trusted to 
self-report their bandwidth contributions, we determine each 
relay’s contribution with a secure bandwidth measurement 
scheme such as EigenSpeed [26]. Using EigenSpeed, relays 
opportunistically measure and evaluate each other’s contribu- 
tions to form an accurate consenus of relay bandwidth that 
has been shown to be resistant to attacks by malicious groups 
of colluding nodes [17], [26]. The measurement process runs 
continuously while a consensus is formed periodically.' 

The bank stores and tracks each relay’s bandwidth contri- 
bution over time, keeping an account balance of contributed 
bytes and updating it with each new bandwidth contribution 
consensus. A relay may collect i digital coins from the bank 
for every a bytes it has contributed, where i is the circuit 
length (£ = 3 in Tor). A coin is constructed using a blind 
signature [25] to prevent the bank from later linking the coin 
to a given relay (the final signature is unknown to the bank). 

Relays use their coins to purchase guaranteed winners from 
the bank (see Section III-C). The bank prevents double spend- 
ing of these by keeping a database of previously spent coins 
that it checks (and possibly updates) when it receives coins 
in a purchase request. The size of the database is bounded by 
a coin expiration period rj. A blind signature simplifies the 
construction of the coin over some electronic cash schemes 
since we do not require double spending detection by a third 
party after a coin has been successfully spent. 

Advantages of using coins in the manner outlined above in- 
clude flexibility and transferability. Coins xre flexible because 
relays may accumulate them during periods when they are not 
actively using Tor as a client, and they are valid as long as the 
bank exists and the coin has not expired. The expiration period 
f] is set so that the bank can store and access a list of spent, 
unexpired coins and may be adjusted as the Tor network scales. 
Section IV shows that currently in Tor 127.5 coins would be 
generated per second. If each coin is a 1024-bit signature, we 
can set rj = 28 days, resulting in list of at most 4.60 GiB and 
fitting into a single machine’s memory. 

A coin is inherently transferable because it is not tied to a 
specific relay, allowing the possibility of a secondary economy 
to form around the purchase and sale of coins. In such an 
economy, it would also be possible for clients who do not run 
relays to obtain coins, improving anonymity by increasing the 
uncertainty of the sources of winning tickets. 

*Tor currently computes the directory consensus every hour, which could 
be amended to include the bandwidth contribution information. 


We configure the ratio of the number of contributed bytes 
a to the number of prioritized bytes /? received in return to 
a = {i + 1) ■ fl. By requiring a contribution \ times that 
of prioritized consumption, we account for transferring data 
through each of the t relays in the circuit, and also ensure that 
new relays that join Tor will only increase its overall capacity. 

C. Purchasing Guaranteed Winners 

Relays will prioritize traffic on circuits for which winning 
lottery tickets are supplied. Winners will be determined using 
a relay-specific permutation that we define below (Eq. 2). Let 
the size of the permutation’s input space be 2^, and let gr : 
[2^] — >■ [2^] be the permutation of relay r. A value x is a 
winner for r if, for yo\\yi = gr{x), j/o ® ?/i < where 

p € [0, 1] is a system parameter. Thus a client that guesses 
an input x randomly will obtain a winner with probability p. 
To guarantee priority, a client can also use coins earned by 
providing service to the network to purchase winners. 

Setting p presents a tradeoff between anonymity and incen- 
tives. Guessing a winner is less likely for smaller values of p. 
In this case, prioritized circuits are more likely to be paid for 
and thus probably originate at a client also running a relay. 
Eor larger values of p, it is more likely that a circuit will be 
prioritized by chance, and there will be less reason to run a 
relay and earn priority. (We discuss this tradeoff in more detail 
in Section IV.) We adopt a setting of p = Eor the 

current Tor network, we estimate n to be 10000, and thus we 
would set p = 10“^/^ « 0.22. 

The construction of the permutations gr is designed to 
provide properties similar to those of a pseudorandom permu- 
tation (PRP), although they are technically somewhat different. 
In particular, the permutations will appear sufficiently random 
to clients that they cannot produce winners with probability 
significantly greater than p. Moreover, they are efficiently 
invertible so that the bank can sell winners by choosing 
V = J/o||yi such that t/o © Pi < p2?'l'^ and providing the 
corresponding input The construction also allows the 

purchase of winners for r to be made while hiding the identity 
of r and the winning number from the bank. 

If we didn’t want to hide this information from the bank, we 
could easily implement the rest of this functionality by using a 
PRP such as AES. The bank could share different private keys 
with each of the relays, and the user would simply purchase a 
winner by presenting a coin and specifying a relay. We wish 
to keep the bank as oblivious as possible, and thus we use a 
more involved construction for the lottery permutations. 

The essential ingredient of the construction is for the bank 
to use blind signatures to obliviously provide a relay-specific 
input to a certain pseudorandom function (PRE) (Eq. 1). We 
then use a two-round version of the Luby-Rackoff construc- 
tion [27] to convert the PRE into a permutation that is largely 
unpredictable to the relay. 

1) Private Evaluation of Pseudorandom Functions: The 
PRE we use is adapted from one suggested by De Cristofaro et 


1. c obtains blinded signature 6x^ 
either from B or as protocol input. 

2. c sends bH{x)xf to B. 

3. B sends H{H{x)xf) to c. 

4. c outputs H{xH{H{x)xf). 

Fig. 2; PRF Protocol: c obtains fr{x) from B 

al. [28] that can be computed obliviously.^ Our construction 
doesn’t provide full obliviousness with respect to the bank, 
but it will provide privacy assuming that the bank does not 
collude with a relay. The PRF used by relay r is 

fr{x) = H{x{H{H{x)xf))), (1) 

where, as described above, x^ G Z’^ is publicly known. 

The PRF Protocol for client c to obtain fr{x) from the bank 
B is given in Figure 2. We leave the option to obtain a blind 
signature in Step 1 as an input to the protocol to enable a 
batch-mode execution that will be used in the final purchase 
protocol. The client will be unable to guess outputs that he 
doesn’t query with better than random chance because the 
relay signature xf never appears in a message from the server 
that hasn’t been blinded or hashed. Moreover, the protocol 
protects the privacy of the client’s inputs (doing so is what 
prevents us from using a simpler PRF, such as H{xfx)). In 
particular, the first unblinded input the bank sees has a factor 
H{x) and thus appears random given that the bank doesn’t 
know X. Including a factor of x before applying H in the last 
step prevents the bank itself from learning the final output. 

2 ) Private Permutation Evaluation: Now we consider how 
to turn this into a permutation. Given / : {0, 1}^' — {0, 1}^, 
the Feistel permutation Df : {0,1}^^ — > {0,1}^^ on x = 
xi||xo, Xi,Xo € {0,1}^, is defined as 

L»/(xi||xo) = (xollxi 0 /(xo)). 

This is invertible because xq is contained in the first k bits, 
and xi can be calculated as /(xq) 0 (xi 0 /(xq)). Luby and 
Rackoff showed that applying the Feistel permutation four 
times with four pseudorandom functions yields a pseudoran- 
dom permutation. We use this idea, but, in our setting, we 
will disallow winners at a relay that result in PRF inputs that 
have been used before. Thus, we can use the Luby-Rackoff 
construction with the single pseudorandom function /^. In 
addition, we do not need the permutation output to appear 
random, but rather the XOR of the output halves. Thus, we 
are able to reduce the number of Feistel permutations to two. 
We therefore obtain a permutation for relay r of 

9r{x) = Df^{Df^{x)) . ( 2 ) 

The permutation in Equation 2 is used by the relay to 
determine if a given ticket is a winner. To purchase a winner, 

^The PRF they suggest is To compute it, the client computes 

H(x), obtains an RS A blind signature on it from the bank, and applies H' 
to the result. 


1. c randomly chooses a and sends a^x^ to B. 

2. B randomly chooses b and sends 6axJ? to c. 

3. c uses the PRF Protocol with input bxf 

to obtain fr(yi) and sets y2 = fr{yi) 0 yo- 

4. c uses the PRF Protocol with input bxf 

to obtain fr{y2) and sets ys = fr{y2) 0 yi- 

5. c outputs j /3 II J/ 2 - 

Fig. 3: Permutation Protocol: c obtains g~^{y) from B 


1 . c pays B a digital coin. 

2 . c randomly chooses yo,yi such that 
2/0 ® 2/1 < 

3. c uses the Permutation Protocol to 
obtain g~^{yo\\yi)- 

Fig. 4: Winner Purchase Protocol: c purchases a winner for r 
from B 


a client will actually choose a winning permutation output 
and apply the inverse permutation to obtain the ticket number. 
Let such an output he y — yi\\yo, yo,yi S {0,1}^/^. The 
Permutation Protocol for a client c to obtain g~^{y) from the 
bank B is given in Figure 3. Observe that this protocol gives 
the client quite a bit more information about the function g~^ 
than a simple oracle query would. In fact, it reveals enough 
information for the client to determine values of g which 
he has not obtained via the protocol. However, this is only 
possible for a negligible quantity of inputs and we will show 
that relays can limit him to obtaining guaranteed priority only 
as many times as he has paid for winners (see Section IV). 

3) Protocol to Purchase Winners: The Winner Purchase 
Protocol run by client c to purchase a winner for relay r 
from the bank B is given in Figure 4. We emphasize that the 
bank will only participate in step 3 of the Winner Purchase 
Protocol if c presents a valid coin. This protocol is run entirely 
over an anonymous onion-routing connection made by c to B. 
To prevent the bank from learning when encrypted circuits 
were made, clients should buy enough winners at a time 
to construct 7 prioritized circuits, should maintain a reserve 
of enough winners to construct 7/2 prioritized circuits, and 
after depleting their reserve below this amount should wait a 
minimum time selected uniformly at random from [ 0 , w] before 
purchasing more winners. 

We set 7 to balance privacy with respect to the bank with 
the flexibility of the recommended buying strategy. Increasing 
7 increases the amount of time between batches of purchases 
observed by the bank and thus the number of other users’ 
prioritized circuits that hide the buyer’s circuits. On the other 
hand, decreasing 7 decreases the number of coins a relay 
should have stockpiled before purchasing winners. We will ask 
a relay to run for at least 3 hours before purchasing winners. 
For a relay providing the current median bandwidth in Tor of 
100 KiB/s [23] and with Tor’s path length of £ = 3, after 3 
hours the relay obtains about 79 coins. Each prioritized circuit 


1 . c runs onion-routing circuit-creation protocol. 

2. For each relay r in the circuit, c sends a TICKET 
cell with either a purchased winner Wr 

or random guess Xr € [ 1 , 2 ^]. 

3. For every (3 bytes that pass over the circuit, 

c repeats Step 2 with new winners or guesses. 

Fig. 5: Circuit Setup Protocol for client c 

costs i coins, and so we set 7 = 26. 

We set uj to maximize the number of prioritized connections 
that could have triggered a purchase without emptying the 
reserve of winners. Thus we set oj to the point at which 
a client’s reserve of 7/2 winners would become empty had 
he been making only prioritized connections. For clients that 
make new circuits at rate r this happens at w = 7 /( 2 r). In 
Tor, r « 1, and so we have w = 13 minutes. 

D. Circuit Setup 

LIRA slightly modihes the onion-routing circuit-creation 
protocol (cf. Section II) to accommodate prioritization. Clients 
use a new TICKET cell type to send a lottery number to each 
relay on a circuit and attempt to obtain priority. A TICKET cell 
has the structure [TICKET, number], where the number held 
contains a value in [0, 2^). This cell is sent to a relay from the 
client over the circuit and is thus onion-encrypted. In addition, 
relays on a circuit signal prioritization status to one another. 
These messages are sent directly over an encrypted pairwise 
connection (e.g. over the persistent TLS connections that Tor 
maintains between pairs of relays) with an identiher indicating 
to which circuit they pertain. 

The Circuit Setup Protocol at the client is described in 
Figure 5. It simply adds periodic lottery-ticket messages to the 
standard circuit-creation protocol in onion routing. Note that 
the ticket messages are sent onion-encrypted over the circuit 
and thus can only be read by the recipient. 

Relays determine priority for their circuits using the Circuit 
Priority Protocol described in Figure 6 . For each position in 
a circuit, a relay maintains priority values for itself, for the 
preceding segment of the circuit, for the succeeding segment of 
the circuit, and for the entire circuit. The relay also maintains 
a counter for the number of priority bytes that are left under 
the current prioritization. Observe that the protocol involves 
explicit signaling along the circuit to synchronize the priority 
status of the relays. Thus, for the circuit depicted at the bottom 
of Figure Ic, even though the middle relay has received a 
winner, it will mark the circuit as DEAD after it receives a 
DEAD relay priority from either the guard or exit relay. 

Also observe that, during the validation of a ticket number, 
the PRF inputs used during the two applications of the Feistel 
permutation (Eq. 2) are stored. If a PRF input used during 
ticket validation has been seen before, then that ticket is 
considered a loser. This prevents a client from reusing old 
winners and from using PRF outputs obtained from the bank 
to construct multiple winners. Finally, note that once a losing 


Upon receiving data cell 

If priority bytes counter is greater than zero 
Reduce priority bytes counter by cell size 
If priority bytes counter is zero 

and self priority status is not DEAD 
Set self priority status to EXPIRED 
Set circuit priority status to EXPIRED. 

Upon receiving priority status from adjacent relay 
Store status and send to other adjacent relay 
If all stored relay priorities are TRUE 
Set circuit priority TRUE 
If any stored relay priority is DEAD 
Set circuit priority DEAD 
Upon receiving TICKET cell with value x 
Compute J/ 0 II 2/1 = 9r{x), storing intermediate 
PRF inputs 

If vo®yi < p2^/2 

and intermediate PRF inputs previously unseen 
and no stored priority status is DEAD 
Set self priority status to TRUE 
Increment priority bytes counter by /3 
Set circuit priority TRUE 

Else set self and circuit priority statuses to DEAD 
Send self priority status to adjacent relays 

Fig. 6 : Circuit Priority Protocol for relay r 


ticket has been observed, the priority status is DEAD and no 
further priority is possible on the circuit. 

The value of /3, the number of bytes for which a winner 
provides priority, provides a tradeoff between user anonymity 
and the incentive to run a relay. A small j3 makes it unlikely 
that a guesser, that is, a user who does not buy winners, will 
maintain priority over the life of a typical circuit. This reduces 
the anonymity of a buyer, who we wish to allow to obtain 
priority for an entire connection. Setting a large /3, assuming 
the price of a winning ticket increases proportionally, causes 
buyers to either use a circuit for a long time, reducing their 
anonymity by increasing the linkability of their connections, 
or to lose many of the bytes for which priority has been 
purchased, decreasing the incentive to earn it. In addition, 
a large /3 increases the granularity of buying winners, and 
so more e-cash must be earned before it can be used, again 
decreasing the incentive to earn e-cash. 

Given these considerations, we use a value of /? that is 
greater than the length of a typical connection. As discovered 
by McCoy et al. [29], over 90% of connections over Tor 
are HTTP connections. Ramachandran[30] shows data from 
billions of web pages showing that the mean size, including 
all embedded content, is 320KB. Cheng et al. [31] show 
that the mean YouTube hie size is 8.4MB. To enable most 
web connections as well as such popular activities as viewing 
videos, we use /3 = lOMiB. 


TABLE I: Bank Costs 


E. Circuit Scheduling 

To improve the quality of service of qualifying traffic — cells 
on circuits for which valid winners have been provided — we 
incorporate ideas from the differentiated services architecture 
(DiffServ) [32]. More specifically, we ensure a relative quality 
ordering between qualifying and non-qualifying traffic using 
a priority scheduling mechanism based on the proportional 
differentiation model [22]. The model aims to provide pre- 
dictable and controllable performance: quality metrics should 
be consistently proportional between classes and the propor- 
tions should be adjustable. 

In the proportional differentiation model, traffic is separated 
into N classes labeled ci, . . . ,ctv- The model states that the 
desired quality measurement qi for each class Ci should be 
proportional to the other classes, where the proportions are 
conhgured with a differentation parameter pi for each class. 
The classes should be scheduled such that the relative quality 
of each class follow the conhgured differentation parameters: 

« e liVl.V; e («| . = « 

where pi < p 2 < ■ ■ ■ < Pn, and a is the measurement 
timescale. Dovrolis et al. explore Proportional Delay Differ- 
entiation and a priority scheduler that differentiates classes 
using queueing delay (packet waiting time) as the desired 
quality metric [33]. The scheduler utilizes two statistics to 
determine which class Ci to schedule at time t: the queueing 
delay Di{t) of the longest waiting packet in Ci, and the long- 
term average delay 5i{t) of all previously scheduled packets 
(i.e., the average queueing delay of packets at the moment they 
are scheduled). The quality metric under Proportional Delay 
Differentiation becomes: 


qi{t) = D,{t) ■ / -f 5i{t) •(!-/) 

where / is an adjustable fraction (0.875 is suggested in [33]). 
A priority is computed for each Ci as Pi{t) = qi{t)/pi{t), and 
the longest waiting packet from the class with the maximum 
computed priority is scheduled next. 

Once a class is selected, the above approach is essentially 
first-come, hrst-served scheduling since each packet’s delay 
timer starts when the packet enters the queue. However, it 
has been shown that an alternative approach is better suited 
to scheduling in the Tor network. In particular, prioritizing 
circuits with a low exponentially-weighted moving average 
(EWMA) circuit throughput may improve performance of 
bursty traffic while minimally harming bulk traffic with higher 
desired long-term throughput [11]. Therefore, LIRA schedules 
using Proportional Throughput Differentiation, where we ad- 
just the quality metric at time t using the EWMA throughput of 
the lowest throughput circuit Ti(t) and the long-term average 
throughput Ti{t) of previously scheduled circuits: 

= Ti{t) ■ f -f n(t) •(!-/) 

where / remains adjustable. The priority is now computed 
for each Ci as Pi{t) = qi{t) ■ Pi{t), and the circuit with the 
lowest EWMA throughput from the class with the minimum 
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computed priority is scheduled next. Scheduling in this model 
allows us to configure the performance payoff associated with 
running a relay, or correctly guessing a winning ticket. 

IV. Analysis 

A. Efficiency 

LIRA preserves all the communication functionality of 
onion routing while providing both anonymity and efficiency. 
This section will consider how LIRA affects the overall 
computational and communication costs of the network. 
Overhead. Clients may purchase a winner from the bank for 
each relay in a circuit to receive /3 = 10 MiB of prioritized 
traffic. Purchasing these winners involves ^ RSA encryptions 
for the client portions of blind signatures and 4£ hashes. This 
cost is on the order of the cost for building a circuit, which is 
continuously incurred throughout a Tor client session. Clients 
that do not purchase winners incur no extra computational cost 
by using LIRA. 

Our goal is to keep relay CPU costs low because, according 
to the Tor developers, the high-bandwidth Tor relays are 
CPU-bound. LIRA introduces some overhead for relays with 
ticket verification, i.e., checking whether or not tickets are 
winners. This process involves evaluating the permutation 
in Equation 2 for every bytes of transferred data. Each 
evaluation involves 6 hash computations, as well as a smaller 
number of multiplications and XORs. The DiffServ scheduler 
has been shown to be efficient [33] since each scheduling 
decision must only compute one priority for each class. 

The bank is involved in distributing e-cash to relays and 
selling winning tickets. To generate e-cash, the bank creates 
a coin for every a|^ = 10{£ -\- l)/£ MiB sent by a given 
relay. Creating a coin involves a single blind signature, and 
these coins are given to the relays using a simple two-message 
protocol. To sell a winner, the bank must verify a coin by 
verifying a signature, provide a blind signature, and then 
participate in the batch PRE Protocol two times, each of which 
involves one hash. 

We now consider the bank costs if the entire network is 
transferring b MiB/s and the fraction of coins that end up being 
used by the relays that earn them is /. Let p = £b/{10{i -f 
1)) be the rate at which coins are generated in this network. 
The rate of costly cryptographic operations and communicated 
messages for each bank service are outlined in Table I. It 
shows that the rate of the cryptographic operations is just a 
fraction of the total rate of traffic on the network. Table I also 
shows that the communication costs at the bank, in terms of 
the number of messages, the size of a digital coin, and the 
size of a ticket number, are similarly small. 


Current Costs in Tor. To get a more concrete idea of what 
the costs at the bank might be in practice, we estimate what 
it would cost for a bank to serve the current Tor network. 
In Tor, b = 1700 and i = 3. The most costly operation by 
one to two orders of magnitude is signature generation. In the 
above setting, the rate of signature generation is 127.5+127.5/ 
per second, where again / G [0, 1]. OpenSSL benchmarks in 
Linux on an Intel Core2 Duo 2.67 GHz machine show that it is 
capable of creating 1705 1024-bit RSA signatures per second, 
and thus a modest machine is easily capable of generating the 
required signatures. 

We also estimate the communication costs at the bank in 
this setting by using a signature size of 1024 bits and a ticket- 
number size of A = 320 bits. Then the bank sends at a total 
rate of 15.94 + 25.90/ KiB/s and receives at a total rate 
of 15.94 + 41.84/ KiB/s, easily manageable with a single 
consumer-grade network connection. 

Comparison to BRAIDS. To further understand LIRA’S 
efficiency, we compare it to the efficiency of BRAIDS [21], the 
state-of-the-art Tor relay incentive design. The cost for each 
client in LIRA and BRAIDS are similar, however, only the 
clients that are purchasing guaranteed winners must pay this 
cost in LIRA as opposed to all clients that receive free tickets 
in BRAIDS. Further, a relay verifying winners in LIRA is at 
least an order of magnitude more efficient than a relay veri- 
fying tickets in BRAIDS; our OpenSSL benchmarks indicate 
lira’s winner verification (6 SHA-1 hashes) takes roughly 
18 microseconds, whereas a BRAIDS ticket verification takes 
roughly 1500 microseconds [21] on the same hardware. 

The most important cryptographic cost is at the bank. 
lira’s bank only needs to cryptographically pay the relays 
for some fraction of the total traffic due to its lottery design. 
On the other hand, the bank in BRAIDS pays for all traffic 
by distributing tickets to all clients. In addition, the number 
of ticket purchases is proportional to the amount of e-cash 
actually used by the relays to obtain prioritized service. If, as 
we expect, many relays altruistically provide more service than 
needed to support their own use, the system gains significant 
efficiency over distributing tickets to clients. 

If we change the parameters of the BRAIDS scheme to more 
conservatively compare LIRA^, we observe that BRAIDS re- 
quires at least 637.5 signatures per second. Even if / = 1 and 
relays spend all their credit, LIRA is more efficient. Moreover, 
BRAIDS requires a less computationally efficient partially- 
blind signature scheme. The signature-generation protocol 
in BRAIDS also has higher communication costs in both 
directions than RSA blind signatures, and thus is easily greater 
than lira’s costs in both directions. 


3We suppose that BRAIDS creates tickets for only half of the network 
traffic, as it is designed to cover Web traffic (58% of Tor traffic [29]). 
Also, we allow each ticket to buy lOMiB of priority, as in LIRA, and we 
give relays a bytes sent/eamed ratio of 1/4, also as in LIRA. We then have 
(1700*3)/(2*4*10)=63.75 tickets created per second, which yields 63.75*20/2 
= 637.5 total signatures per second when ticket exchanges are included. 


B. Anonymity 

We are interested in the extent to which the use of LIRA 
affects the anonymity of onion routing. Onion routing security 
is well-explored in the literature [24], [34], [35], [36], [37], 
and its vulnerabilities generally exist after adding our incentive 
system. Therefore, our goal is to prevent whatever anonymity 
is provided by onion routing from being significantly de- 
graded. In this section we denote by negl(A) a function that 
is negligible in A 

Single Connection. Consider first a network adversary ob- 
serving a single connection below the priority cutoff length 
of p. If the adversary is observing at a guard node, the user 
may be identified as running a relay if he is connecting to the 
guard from it. However, the multiple connections case shows 
that this would be quickly learned by the guard anyway. Thus 
it is a good idea for the user to use his own relays as guards. 

Assuming the adversary is not observing at a guard node, 
from the adversary’s perspective, LIRA simply adds TICKET 
cells and status signaling messages between pairs of relays. 
Users only directly affect the TICKET cells. Guessers and 
buyers generate these cells according to different distributions, 
potentially leading to some deanonymization. The difference 
lies in the probability that the TICKET cells contain a winner 
or not. Therefore, we need only consider an adversary’s 
observations about whether or not the user inserts winning 
tickets into each of the relays on a circuit. 

Suppose that a user does provide winners for an entire 
circuit. This happens with probability 1 for buyers and for 
guessers. The adversary can easily learn that submitted tickets 
were winners if he controls one of the circuit’s relays. He may 
also learn this by observing the speed of traffic to and from 
a destination under his observation. Over time, the adversary 
can learn the distribution of traffic speeds for prioritized and 
unprioritized traffic and use the separation between these (as 
demonstrated in Section V) to infer the priority status of a 
given observed connection. Assume that buyers consist of 
the m relays and guessers consist of the other users of the 
network at a given time, and that each user is a priori equally- 
likely to create a circuit. Then the probability that the source 
of a connection is a given relay, based only on its circuit 
prioritization status, is l/{m + {n — m)p^), and the probability 
that it is a given non-relay is p^ / {m + {n — m)p^). 

Now suppose that a user’s tickets are not winners for the 
entire circuit. This happens with probability 0 for buyers and 
1 — p^ for guessers. As before, the adversary can determine 
this in several ways. Buyers never fail to provide a winner, 
and so the adversary can infer that the source is a guesser. 
Given n — m guessers, the probability that the source is a 
given one is l/{n — m). (Of course buyers could intentionally 
fail to submit winning tickets at some relays periodically to 
complicate this analysis. We do not evaluate such possibility 
in this paper.) 

We are most interested in the case that there are relatively 

^A function / that is negligible in A decreases faster with A than any 
inverse polynomial. That is, /(A) = o(l/A*^) for any k. 


few buyers, as that would be true currently if LIRA were 
deployed in Tor, and we would expect it to remain so as long 
as the cost of running a relay is high relative to the benefit 
of anonymity for most users. In this case, the probability 
that a given buyer is the source of a single short prioritized 
connection, based only on its circuit prioritization status, is 
roughly l/(m + np^). With p — this becomes 

l/{m + ^/n). Thus, we can see that uncertainy over the source 
increases with the total number of users n, a desirable property 
of onion routing that we want to preserve. With few buyers, 
the probability that a given guesser is the source of a single 
short unprioritized connection, based only on the circuit’s 
prioritization status, is roughly 1 /n, which is the best possible. 

Of course, an adversary need not only take into account the 
prioritization status of a relay for purposes of deanonymiza- 
tion. Indeed, as discussed, all attacks on onion routing it- 
self maybe be used in addition to the information provided 
by LIRA. However, the action of the incentive system is 
independent of the underlying onion routing protocol, and 
therefore the effect on deanonymization is simply to weight the 
distribution an adversary would otherwise infer. For example, 
suppose that, excluding the observations from the incentive 
system, the adversary can infer that the source is a given user 
with probability pi . If that user has probability p 2 of achieving 
the priority observed, then, including those observations, the 
probability of the user becomes (proportional to) pip 2 - One 
consequence of this as that LIRA increases the posterior 
probability of a buyer by at most 1/p^. 

Multiple Connections. Circuits on which more than /3 bytes 
are sent include multiple TICKET cells from users. The above 
analysis applies to any one priority status, but taken together 
they degrade the anonymity of the user to the point that they 
are essentially identified as either a buyer or a guesser. Suppose 
a user’s circuit transfers more than {k — l)/3 bytes. This will 
happen when a single connection exceeds that amount. It can 
also happen if the total volume of multiple connections sent 
over the same circuit exceed that amount.^ In this situation the 
user updates his priority status k times. The probability that 
a guesser maintains priority through all the updates is p^^. 
Therefore, such a circuit created by a buyer quickly identifies 
him as a buyer, and the probability that it is a given buyer 
conditional only on the priorities observed is 1 /(to -f (n — 
m)p^^). Guessers are always identified as guessers when the 
tickets they submit fail to be winners, and this happens with 
an increasing likelihood of 1 — p^^. 

Users making many circuits over time face the possibility of 
a similar decrease in anonymity. If an adversary can observe 
the priority status of fc of a user’s connection and link them 
together as belonging to the same (unknown) user, the resulting 
anonymity is just as if the user updated the priority status of 
a given circuit k times. Some ways the adversary may be 
able to link connections include controlling a destination at 

^The amount of traffic sent over a circuit depends on the relative rates at 
which circuits and connection are created and destroyed. Tor only puts new 
connections on circuits that have been used for less than ten minutes, with a 
preference among used circuits for the youngest. 


which users are active over long-lived sessions, controlling 
some exit nodes and linking together connection by related 
activities, and controlling some middle nodes and observing 
connections coming from the same guard nodes. The adversary 
is also be able to link connections at a guard node because 
they come from the source directly. A user running a relay 
may hope to hide that fact from a given guard by connecting 
to the anonymity network from a different location and buying 
tokens from a guard anonymously through a different guard. 
However, if he consistently buys priority, his guards will 
quickly determine that. 

We note that hiding over the long term the fact that better 
service is being purchased seems to be a fundamental issue that 
any scheme will suffer from to some degree. In BRAIDS [21], 
for example, normal users receive fewer coins than relays, and 
so they can only be confused with relays if they save up many 
coins before buying, and thus few of them can buy at any one 
time. On the other hand, allowing users to purchase service 
without running a relay, which we ignored in our analysis due 
to uncertainty, has the potential to attract many more users than 
those that run relays. The Torservers.net project [14] already 
demonstrates that many prefer donating money to running 
relays. (Note that this also presents a mechanism whereby 
purchasing priority can indirectly add commensurate capacity 
to the network if all proceeds of such sales are directed into 
the purchase of more capacity, such as Torservers.net does.) In 
addition, the widespread use of VPNs for Internet security and 
blocking resistance indicate a willingness to pay for privacy. 
Bank Privacy. We assume that the bank is semi-honest and 
only observes messages sent to it. The bank only observes the 
amount of e-cash earned by relays, when cash is transferred 
among users, and the purchase of winners. Clearly, then, 
the bank doesn’t learn anything about the destinations of 
connection through the anonymity network, and therefore 
users have relationship anonymity with respect to the bank. 
However, LIRA protects user privacy even further. 

First, all bank purchases are made using anonymous connec- 
tions and anonymous coins. Therefore the bank doesn’t learn 
who is spending e-cash and buying service in the network. 

Second, clients batch and randomly time their purchase 
of ticket winners to hide when prioritized circuits are made 
from the bank. Clients should purchase winning tickets 
at a time. If a relay prioritizes all his circuits and makes 
them at Tor’s rate r « 1 per minute, he purchases winners 
every 7 = 26 minutes. Moreover, the time of the purchase 
triggered by a prioritization that reduces a client’s reserve 
of winners below the 7/2 threshold is hidden from a bank 
within a period of w = 13 minutes. To get an idea of how 
many other prioritizations occur during these time periods, 
consider n = 10000 users making circuits at rate r, each 
gaining priority with probability p^ = Xj^pn. Then during 
a 26 minute period between purchases there are an expected 
'ynp^r = 2600 prioritized circuits from other users and during 
a 13 minute period there are an expected 1300 such circuits. 

Third, the Winner Purchase Protocol hides from the bank the 
relay identity and the ticket number of a purchased winner. The 


1. B sends challenge relays tq ^ ri to C. 

2. C chooses a random bit z G {0, 1}. 

3. C obtains a coin from B. 

4. C executes the Winner Purchase 
Protocol with B for relay 

5. B outputs a guess z' for the value of z. 

6. The experiment value is 1 if z' = z, 0 if not. 

Fig. 7; WPP-REL-IND experiment between B and C 


indistinguishability experiment WPP-REL-IND between the 
bank B and a challenger C shown in Figure 7 tests how well 
the bank can determine the relay of a purchase. Theorem 1 
shows that the observations a bank makes during a purchase 
for given relay are indistinguishable from the observations 
made during a purchase for a different relay. 

Theorem 1: In the Random Oracle Model, 
Pr[WPP-REL-IND = 1] < 1/2 -f negl(A). 

Proof: Model H as a Random Oracle. Let Z represent 
the random bit chosen in Step 2 of the WPP-REL-IND 
experiment. We compare this experiment when Z = 0 and 
Z = 1 and show that, except with negligible probability, a 
given view of the adversary is equally likely in both cases. 
Let B make queries Qii Q 2 , ■ • ■ , Qt to i7 in that order during 
the experiment. 

C begins the experiments for both Z = 0 and Z = 1 by 
paying B a coin. Coin generation and payment is independent 
of relay selection, and thus the observations B makes as part 
of those processes does not affect the probability of later 
observations and can be ignored. 

Next, C chooses O < To, Li < 2'’'/^ such that Tq 0 Ti < 
p2^/2. We can view C as choosing Yi independently and 
uniformly at random such that O < Yi < 2^/^. This implies 
that C chooses Tq in Step 2 independently and uniformly at 
random from the p2^/^ values that satisfy 0 < Tq 0 Ti < 
p2^^ We let 

Y2=frAYl) 

= Yo(BH{YiH{H{Yi)xf^ 

denote the value to be computes in Step 3 of the Permutation 
Protocol. Then we can define Collision to be the event that 
Qi = Yi or Qi = Y 2 for any I < i <t. 

C next sends a^Xrz to B to obtain the blinded signature 
where a is chosen independently and uniformly at 
random. As in the preceding, this observation can thus be 
ignored. 

Next, C sends Xi = bH(Yi)xf^ to B. Consider the 
queries Qi, - ■ ■ ,Qt^ that occur before C queries H{Yi). Y\ 
is independent of all observations of B at this point, and 
therefore the probability that Qi = Yi for some 1 < z < is 
2“^/^ G negl(A). Similarly, Tq is independent of all of B’s 
observations, and thus the probability that Qi = Y 2 for some 
1 < z < ft is p2“^/^ G negl(A). Assume from this point on 
that this doesn’t happen. 


The result of the query Yi to H is thus independently and 
uniformly random. Thus the probability of Xi is the same 
whether Z = 0 or Z = 1. The former case, of course, 
implies that H{Yi) = Xi/{hxf^), while the latter implies that 
i7(Fi) = Xi/(6<). 

The next message from C to i? is X 2 = bH{Y 2 )xf^. 
Let Qi,...,Q (2 be the queries that B makes to H up to 
the point that C queries Y 2 . We have already assumed that 
Qi ^ {Yi,Y2} for 1 < z < < 1 . 

■ 

We can define an experiment similar to WPP-REL-IND 
to test how well the bank can guess the ticket number of 
a purchase. It can be shown that the bank succeeds in that 
experiment with at most a negligible amount over a random 
guess as well. 

C. Incentives 

LIRA is designed to create an incentive for users to run 
relays or otherwise contribute to the system. We explore in 
Section V the extent to which it successfully provides better 
service to users that receive priority. Here we consider if users 
must, as we intend, earn e-cash in order to increase the amount 
of priority they can obtain. Again we denote by negl(A) a 
function that is negligible in A. 

We first note that the possibility of cheating the system 
is an important consideration but one less important than 
performance and preserving anonymity. Regardless of whether 
or not a user can deviate from the protocol to obtain more 
priority, the anonymity and performance properties of the 
system still hold. Thus system operators could experiment 
with the use of LIRA without compromising the properties the 
network already provides. Furthermore, the amount of cheating 
that will occur in practice in a network protocol is unclear. 
BitTorrent, for example, is susceptible to cheating [38], [39], 
but it tends to perform well in practice. Somewhat low barriers 
to cheating may well be sufficient to induce most participants 
to comply. 

LIRA is designed to force users to pay in order to obtain 
a winner with probability greater than p. It achieves this by 
using an e-cash scheme and a novel cryptographic lottery. 

In the e-cash scheme, users must present valid digital coins 
to participate in the Winner Purchase Protocol (Fig. 4). The 
e-cash scheme prevents coin forgery or double spending. 

The winners themselves are obtained by participating in the 
Permutation Protocol (Fig. 3). This protocol allows users to 
observe much more about than just the output. However, 
the intermediate PRF outputs that the users observe are only 
allowed by a relay to appear in one winner. If another ticket 
is submitted with a previously seen PRF value, the relay will 
treat it as a loser. Thus these intermediate values are of no use 
in producing more winners than were paid for, and on inputs 
with unseen intermediate PRF values, the XOR of the halves 
of the lottery permutation does indeed appear random. 

We formalize this property in the security experiment PP 
between an adversary A and a challenger C shown in Figure 8. 
We will show that A succeeds in this experiment with at most a 


1. A outputs relays r = {ri, . . . , rj,} 
and a challenge relay ^ r. 

2. C outputs random values {x ^ , ■ • ■ , 
in Zd and signatures {xf^, .. 

3. C executes the Permutation Protocol with A 
as many times t as requested. 

4. A outputs X = {x\, . . . ,xt+i}. 

5. If Vij/o ®y\< where yl\\y\= gr, {x,) 

and no intermediate PRF input would be reused 
during protocol evaluations of the gr^{xi), 

the experiment value is 1; else it is 0. 

Fig. 8; PP experiment between A and C 


1. C generates RSA parameters (M,e,d) 
and outputs (M,e). 

2. A outputs relays r = {ri, . . . , Xk} 
and a challenge relay Tc ^r. 

4. C outputs random values {xr^ , ■ ■ ■ , Xr^ , Xr ^ } 
in Zd and signatures , . . . , x'^^}. 

5. C executes the PRF Protocol with A some t 
number of times. 

6. A outputs X = {xi, . . . ,xt}, {yi , . . . , yt}, Xc ^ x. 

7. C randomly chooses z G {0, 1}. 

8. C outputs fr^ {xc) if z = 0 and else a random y. 

9. A outputs a guess z' . The experiment value is 1 
if z' = z and = fr^{xi). Otherwise it is 0. 

Fig. 9; PRF experiment between A and C 

negligible probability greater than p. But hrst, we show that the 
PRF Protocol actually provides the PRF properties. The PRF 
experiment shown in Figure 9 tests whether, after executing the 
PRF Protocol some arbitrary number of times t, an adversary 
A can distinguish (x) from a random value for more than 
t inputs X, where Xc is some challenge relay. Lemma 1 shows 
that the adversary succeeds in this experiment with probability 
at most a negligible amount over random chance. 

Lemma 1: In the Random Oracle Model and under the RSA 
assumption, Pr[PRF = 1] < 1/2 + negl(A). 

Proof: We can reduce winning this game to solving the 
RSA problem. We construct a simulator S for the PRF chal- 
lenger C and random oracle H. S implements H internally. S 
implements parameter selection by relaying RSA parameters 
from the RSA challenger to PRF adversary A. S randomly 
selects the relay signatures xf., computes the relay values 
Xn from them, and randomly selects Xr^- S executes the 
challenger side of the PRF Protocol by storing the response 
values Wi = H{xi) output by A and using random values vt 
for each H{H{xi)xfJ. 

Step 1 of the PRF Protocol is random, and so the distribution 
of these values given A’s view is accurately produced by S. 
The value for H{H{xi)xf ) is indeed random in A’s view 
unless the response from A in Step 2 of the PRF Protocol 
is such that xf^Wi is equal to some value queried of H by 


A. S can check for this possibility by dividing all queries 
for H by each new Wi received from A, raising it to the 
power e, and comparing to Xr^- If any verihcation succeeds, 
S submits that value to the RSA challenger. Under the RSA 
assumption, the probability that this happens is negligible. 
Assuming this doesn’t happen, C randomly chooses a bit z and 
outputs a random y. If the outputs Xi and yi of A are such that 
H{xi) = Wi and yt = H{viXi), then S has not “programmed” 
H with a value for H{xc)xf (i.e. choosing a value without 
knowing the input). S again checks if H[xc)xf has been 
queried by dividing all queries by H{xc) and raising to the e, 
sending to the RSA challenger if so. Thus this happens with 
negligible probability. Assuming it hasn’t, frA^c) is random 
from A’s perspective, and the random y from C has the correct 
distribution, z is random and independent of y, and thus z' = z 
with probability 1/2. 

Therefore, overall C presents the correct view to A except 
with negligible probability, and thus we have Pr[PRF = 1] < 
l/2 + negl(A). ■ 

Using Lemma 1, we can now show that the adversary does 
not have an advantage in hnding more than t winners under 
the permutation g^. 

Theorem 2: In the Random Oracle Model, Pr[PP = 1] < 
p + negl(A). 

Proof: After executing the Permutation Protocol t times, 
A only obtains the value of fr^ on 2t inputs. Therefore, among 
the 2{t + 1) values to which is applied according to 
Equation 2, there must be at least one repeated value or one 
on which A has not evaluated fr^ . If there is a repeated value, 
then the experiment value is 0. Otherwise, there is an unknown 
evaluation of fr^ that appears random to A by Lemma 1 . If this 
input to fr^ appears as half of one of the Xi, the probability 
that its value under results in a known input to in the 
next Feistel permutation is thus negligible, and so one half 
of grAxi) appears random to A. If the unknown input 
appears after the hrst Feistel permutation of some Xi, one half 
of g^Axi) again appears random to A. In either case, the XOR 
of the halves of some g^Axi) appears random to A. Thus that 
Xi is a winner with probability negligibly close to p. ■ 

While this theorem shows that users can only themselves 
produce unused winners with probability p, a user may try to 
game the network by creating circuits and determining their 
priority. If he attempts to do so without colluding with any 
relays, he must determine the priority of the circuit from its 
performance alone. Suppose that doing so requires that he 
send or receive at least c cells on a circuit. Then, to obtain 
a circuit with priority, the user must transfer an expected cjp 
total cells. If the cost of tranferring these cells is comparable to 
the amount of traffic a relay needs to transfer in order to earn 
enough coins to build a circuit, a rational user might choose 
to take that more-reliable option. 

A user might also run or collude with a relay in order to 
obtain priority without paying. A relay on a circuit is able 
to determine from the messages between adjacent relays on 
a circuit its priority status. Therefore, a user could collude 
with a guard node to create and destroy circuits until one with 


priority is obtained. Similarly, the user could collude with a 
middle or exit node, although given that the user in this case 
is presumably known to the colluding relay, it would seem 
only to improve performance without decreasing anonymity 
to directly connect to that relay. A simple remedy for this 
attack that renders it equivalent to testing and creating circuits 
is to defer the activation of priority on a circuit until some 
number c of cells have passed in either direction. The initial 
traffic on a circuit is fast even without priority due to EWMA 
scheduling, and so the performance impact should be minimal, 
although we have not implemented it in our experiments. An 
additional possible attack is for a colluding relay in the middle 
of the circuit to lie about the priority status of either side in 
order to get partial priority of a circuit. However, we again 
observe that it would seem to make little sense for a user to 
use a colluding relay as a middle node rather than connect 
directly. Also, for all attacks that involve a relay, the costs 
associated with running a relay are already being paid, and 
it would have to be the case that the cost of simply adding 
capacity is more than the cost of running a cheating scheme. 

Finally, we observe that similar opportunities for cheating 
exist in other recent incentivization schemes for anonymous 
communication. The Tortoise scheme of Moore et al. [9] 
allows users to create many circuits to avoid throttling, similar 
to the multiple-circuits attacks in LIRA. Also, the BRAIDS 
design of Jansen et al. [21] is susceptible to malicious guards 
as well, in that guards can easily steal the winning tickets 
intended for their users. Thus while LIRA does not eliminate 
cheating, it does offer a substantially new balance among 
competing priorities. 

V. Experiments 

We simulate LIRA in an effort to understand the perfor- 
mance benefits possible when running our incentive scheme. 
Our experiments are done using Shadow [40], a scalable, 
high-fidelity network simulator that is capable of running real 
Tor binaries as plug-ins (using the available Shadow plug-in 
called Scallion [41]). Shadow allows us to create a private 
Tor network on a single machine and avoid privacy risks 
associated with live network experiments. Shadow experiments 
are completely controllable and repeatable, and are faithful to 
Tor’s protocols since Shadow runs the real Tor software. In 
this section, we describe our configured experimental network 
environment, quantify its consistency with public Tor network 
performance, and explore how LIRA affects performance and 
improves incentives for a variety of users. Note that all of the 
experiments described in this section are repeated ten times to 
diminish random experimental variances, and each uses Tor 
software version 0.2.3. 13-alpha. 

A. Network Model 

Shadow requires a complete-graph network topology that 
includes properties such as upstream and downstream band- 
widths, latency, jitter, and packet loss. As network modeling 
is itself a challenging research problem, we rely on previous 
Tor network modeling contributions by Jansen et al. [42]. 


Their work considers every element of the Internet and the 
Tor network itself that must be modeled to run accurate Tor 
experiments in Shadow. Their model is built using real Internet 
measurements from GeoIP [43], iPlane [44], [45], and Net 
Index [46], and is validated with multiple experimentation 
platforms and data from the live Tor network itself [23]. 

We now give an overview of the Tor network model used 
in our experiments and discuss how it was modified from the 
original, the full details of which are presented in [42]. Our 
private Tor network consists of 50 generic HTTP servers, 50 
Tor relays, 500 Tor clients. Of the 50 Tor relays, there is 1 
directory authority, 20 exit relays, and 29 non-exit relays. 

Although the original model configured 475 web and 25 
bulk clients, a wider range of client applications would provide 
a more realistic traffic distribution. Therefore, we slightly 
modify the clients to better approximate Tor’s protocol distri- 
bution as described in [29] and [47]. We configure 10 instant 
messaging clients (im), 465 web HTTP clients (web), 20 bulk 
HTTP clients (bulk), and 5 peer-to-peer clients (p2p). The 
im clients download 1 KiB files, pausing for one to five 
seconds after finishing one download and before starting the 
next. The web clients download 320 KiB files and pause for 
1 to 20 seconds. The bulk clients continuously download 5 
MiB files without pausing. All of the im, web, and bulk 
clients choose a random HTTP server for each download. The 
p2p clients form a “swarm” around a single 700 MiB file 
that is managed by a p2p authority. Each pair of p2p nodes 
connect and continuously exchange 16 KiB blocks of the file 
without pausing. Payload download times are measured as an 
indication of network performance. 

Model and Simulation Accuracy. As we modified the model 
as originally described and validated in [42], we re-evaluate 
the consistency of Shadow’s results with live network data. 
To determine how well our modeled network approximates 
client performance in the public Tor network, we compare 
download times in a vanilla Tor experiment with measurements 
of Tor collected by the TorPerf measurement system [48]. 
TorPerf downloads 50 KiB, 1 MiB, and 5 MiB files through 
the Tor network to monitor performance, and records various 
download times. Because our clients download differently 
sized files than TorPerf, we compare the time to receive the 
last byte of each of our experimental downloads with the 
time to receive the closest byte that is reported by TorPerf. 
As shown in Figure 10, Shadow does a reasonable job of 
characterizing the expected performance of the public Tor 
network. Performance for im and p2p clients are consistent 
with TorPerf measurements (Figure 10a), as are web and 
bulk downloads below approximately the fiftieth percentile 
(Figure 10b). 

The difference in performance in the upper half of the 
distributions is possibly due to Tor’s scheduling policy [11], 
in which circuit priority decreases as its throughput increases. 
TorPerf will have higher expected priority than clients in our 
experiments since TorPerf downloads once per circuit whereas 
our clients download multiple times per circuit. Note that we 
were unable to confirm this suspicion beyond reasonable doubt 




(a) im and p2p clients (b) web and bulk clients 

Fig. 10: Shadow and public Tor performance are reasonably consistent for various transfer sizes. 


due to a lack of experimental single file circuit downloads. 

B. LIRA Prototype 

We implement a research prototype of LIRA as described 
in Section III by directly modifying the Tor source code. 
To understand how to attribute changes in performance, we 
run separate experiments using the default EWMA circuit 
scheduling algorithm (vanilla Tor), our new Proportional 
Throughput Differentiation scheduler (diffserv) based on work 
by Dovrolis et al. [33] (see Section III-E), and various LIRA 
configurations (lira). 

Class Differentation. We configure our new prototype sched- 
uler with “paid” and “unpaid” classes ci and C 2 , and dif- 
ferentiation parameters pi — 1.0 and p 2 = 10.0. Priorities 
are weighted by taking fraction / = 0.875 of the head-of- 
queue circuit EWMA, and 0.125 of the long-term class average 
EWMA. The EWMA throughput algorithms in both classes 
are configured with a 30 second half-life, which is also the 
default in our vanilla experiment and in public Tor. In our 
diffserv experiment, we isolate the new scheduler from the 
LIRA prototype: all clients are categorized in the unpaid class 
and there is no ticket guessing or buying. Eor each relay in 
our lira experiments, there is a corresponding client who uses 
that relay’s winners to receive priority for all of its downloads. 
Of these 50 “paid” clients, we configure 1 im client, 47 web 
clients, 1 bulk client, and 1 p2p client. The remaining clients 
are “unpaid” and will only receive a prioritized circuit by 
correctly guessing with probability p = 0.01. Each prioritized 
circuit may be used for /3 = 10 MiB of data transfer, after 
which new guesses are submitted. 

As shown by the cumulative distributions of download 
times in Eigure 11, the new scheduler appears to give slightly 
preferential service to low throughput im clients and slightly 
worse to high throughput p2p clients. The scheduler tends to 
perform slightly worse than Tor’s default scheduler, possibly 
because our prototype implementation has not been optimized. 
Our diffserv experiment provides a base upon which LIRA 


may be compared. The fundamental mechanism provided by 
the scheduler that is used to create performance incentives is 
tunable class differentiation. Eigure 11 shows the scheduler’s 
ability in this regard, as paid downloads are clearly differenti- 
ated from unpaid downloads. Note that the loss in performance 
for paid im downloads in Eigure 1 la is an artifact of the small 
sample (a single im client) and high latency due to unfavorable 
placement in the topology. 

New Relay Capacity. Eigure 11 shows performance in a 
network where only the existing Tor relays receive priority. 
We now explore a situation where several existing clients 
begin routing traffic for Tor. We consider networks where 5% 
and 15% of the existing client base® begin running a relay, 
adding a total of 25 and 75 relays and newly-paid clients to 
the existing sets of 50. Rationally, each new relay severely 
rate-limits its contribution so as to earn only enough winning 
tickets to support the expected throughput requirements of its 
client as computed from our vanilla experiment. This is a 
conservative estimate. Each client contributes four times its 
expected client throughput since LIRA will prioritize 1/4 of 
a relay’s contributed bytes when £ = 3. Therefore, rate-limits 
are set to 20 KiB/s for those running im clients, 80 KiB/s for 
those running web clients, 340 KiB/s for those running bulk 
clients, and 128 KiB/s for those running p2p clients. Note 
that 1/3 of the added relays are exit relays, roughly the same 
proportion as in the current Tor network. 

The rate-limiting outlined above results in 6.5% and 17.1% 
total additional network capacity, and represents a slightly 
pessimistic approximation of expected client contributions. To 
understand both extremes of the range of possible user behav- 
iors, we configure other networks where the same 15% of new 
relays chosen above do not rate-limit their contributions. In the 
non-rate-limited networks, new relay bandwidth is sampled 
from the Net Index distribution [46] and results in a 95.7% 
and 383.5% increase in network capacity. Eigure 12 shows 

^Of the 5% of clients that begin running relays, we select 1 im, 23 web, 1 
bulk, and 1 p2p. Of the 15%, we select 2 im, 69 web, 2 bulk, and 2 p2p. 




(b) 320 KiB web clients 




(c) 5 MiB bulk clients 


(d) 16 KiB p2p clients 


Fig. 1 1 ; Client download time distribution in vanilla Tor, when using our proposed scheduler, and after adding LIRA’S design 
modifications. LIRA adequately differentiates performance for paying clients without additional capacity. 


the result of additional capacity on client performance. As 
expected and not surprisingly, the added capacity results in a 
net increase in overall performance over LIRA without new 
relays, even under our rate-limiting scenarios. The net benefit 
to the network increases for all clients types, and more dra- 
matically as more capacity is added. Our results confirm that 
LIRA (using the proportional throughput scheduler) enables 
performance incentives for contributors. 

VI. Related Work 

Several incentive schemes have been proposed for mix- 
nets [49], [50], [51] but do not directly apply to low-latency 
anonymous communication networks or Tor. Incentive designs 
for Tor include PAR [19], a scheme where relays accept real 
monetary payments from clients in return for routing service. 
PAR separates payments into anonymous coins paid by clients 
to guard relays, and more efficient identity-bound coins paid to 
the remaining relays. PAR and a similar micropayment scheme 
called XPAY [20] require an online bank to participate in the 
routing protocol to verify that the coins have not been double- 


spent. LIRA, however, is much more scalable as it does not 
require the bank to be involved in any routing transactions. 
LIRA also does not suffer from the fundamental trade-off 
between double-spending detection and accountability that 
plagues PAR and XPAY, wherein anonymity inherently de- 
creases as the ability to detect cheaters improves. 

Ngan et al. propose a lighter-weight scheme in which 
the fastest 7/8 relays are marked with a “gold star” in the 
public Tor directory based on measurements by the directory 
servers [18]. These relays are given priority as they build 
circuits through other gold-star relays, and enjoy improved 
performance because only fast relays receive gold stars. Un- 
fortunately, relay anonymity is reduced because the set of 
potential initiators of a prioritized circuit (the gold-star relays) 
is much smaller than that of an unprioritized circuit (any active 
client). LIRA manages the small anonymity set problem by 
allowing every user to receive priority by correctly guessing 
a winning ticket. 

Jansen et al. propose BRAIDS [21], an incentive scheme 
that, similarly to LIRA, eliminates the double-spending prob- 
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Fig. 12: Client download time distribution as clients begin to run relays. Adding additional capacity as shown results in a net 
increase in performance considering both paid and unpaid clients. 


lem by using relay-specific “tickets”. Each relay may directly 
prevent the double spending of its tickets without needing 
to contact the centralized bank. BRAIDS aims to improve 
anonymity for relays by distributing tickets to all clients, 
using existing guard nodes as proxies for distribution. This 
strategy limits the total number of tickets that may exist 
in the system due to bank resource constraints and reduces 
payment flexibility. LIRA is more efficient in this regard since 
it must only manage ticket transactions for relays providing 
service — a much smaller set than that of all clients. BRAIDS 
also differentiates service [33] by asking clients to specify 
and pay for the desired class (“high throughput” or “low 
latency”), which may partition clients and negatively affect 
their anonymity. Conversely, clients do not choose their desired 
class in LIRA. 

As an alternative to using e-cash or other payment-based 
cryptographic mechanisms to provide incentives, Moore et al. 
suggest in Tortoise [9] a universal rate limit of Tor clients 
and an exemption from such throttling for relays marked 
as stable and fast in the consensus. Unfortunately, this 


approach suffers from anonymity problems similar to the gold- 
star approach described above: the anonymity set of a given 
circuit is limited to a subset of relays, and the timing of 
relays’ priority status appearing in the consensus leaks infor- 
mation that enables an intersection attack over time. LIRA, 
however, provides strong anonymity for well-dehned spending 
levels. As in LIRA, Tortoise clients may multiplex traffic over 
multiple guards to evade throttling, thereby weakening the 
incentives provided by the system. 

There has also been some work considering the behavior of 
participants in an anonymous-communication network from 
an economic perspective. Acquisti et al. [52] describe the 
costs and benefits of anonymity-network users, identify the 
challenges in designing systems that cope with selfishness, 
and present some possibilities for solving those challenges. 
Humbert et al. [53] provide an analysis of using a scrip system 
to incentivize selhsh agents in a cooperative privacy-enhancing 
system such as an anonymity network. They establish the 
existence of a Nash equilibrium, examine its social welfare, 
and show how to manage the supply of scrip. Future study of 


sociological behaviors in LIRA would be interesting should 
the system be deployed. 

VII. Conclusion 

The Tor network suffers from performance problems par- 
tially caused by a lack of relays willing to altruistically 
volunteer bandwidth. This paper presented LIRA, a novel 
incentive scheme that increases performance for those who 
contribute to the network by running a relay. We have shown 
that clients who choose to run relays enjoy faster downloads 
than those who don’t, due to a novel ticket lottery design and 
a scheduler that differentiates service for winning tickets. 

LIRA provides a higher degree of anonymity than previous 
proposals while eliminating the need for clients to contact the 
bank since, with tunable probability, clients can randomly self- 
produce winning tickets. 

There are numerous directions for future work. Among 
them is developing a better understanding of the economics 
of anonymous incentives and how rational users might be 
expected to behave in LIRA or a similar design. Also useful 
would be a modified incentive structure that provides non- 
linear payoff for contributed capacity and higher payoff for 
more desirable relays such as bridges, exits, and those in 
more diverse geographic locations. A distributed bank that 
functions securely within Tor’s trust model would improve 
scalability. Finally, better defenses against strategies for at- 
tempting to cheat the system and improved protection against 
long-term anonymity problems associated with linking paid 
high-throughput users would not only benefit LIRA, but any 
system attempting to provide anonymity-protected incentives. 
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